Engineering manager#

Probably the most common path out of a coding career is becoming an engineering manager (EM). In many organizations, EMs:

  • Make more money
  • Have more impact
  • Have a more central position in the company hierarchy and information flow
  • Spend less time worrying about implementation details.

However, this isn’t always true, as we will explore later.

Next step of your career#

You will spend most of your coding career reporting to EMs, so it might feel natural to view that as the next step. Even more likely, you harbor the armchair quarterback’s niggling suspicion: “I could do that job better!”

“‘Things would be different if I was in charge,’ the belief that authority is an all-powerful magic wand you can wave and fix things.”

- Mark Roddy

Companies also naturally want to take their best coders and put them in charge of other coders. Despite the best efforts of companies to create equivalent individual contributor career tracks, the dearth of good managers means that most organization incentive structures encourage some form of Peter Principle.

Huge career change#

However, heed the advice of basically everybody who has ever gone from engineering to engineering management; it is a huge career change. You go from developing software to working on peopleware. If you are in the right headspace for the role, you will see this as a good thing! Humans are a part of your systems, too!

Huge career change

“Becoming a manager is not a promotion; it’s a lateral move onto a parallel track. You’re back at junior level in many key skills.”

- Sarah Mei

Responsibilities#

As an engineering manager, you have the need to do the following things:

Hiring and managing#

Your primary output is no longer code; it is teams (and, as you rise up, teams of teams). Therefore, you will spend a huge amount of your time hiring and managing. The amount of time you spend in high-stakes crucial conversations becomes exponentially higher.

Hiring and managing

Follow processes#

You can no longer throw a hack together to get things done; you need to follow the process and get buy-in more than ever. Progress will seem glacial compared to what you are used to.

Follow processes

Avoid micromanaging code#

You should help set technical standards but avoid micromanaging code. This is a very fine line to draw, especially if your identity and sense of self-worth are primarily based on your technical expertise. Nobody likes the EM who “swoops in and poops” on their work.

You need to trust your engineers to make their own judgments and their own mistakes (within reason). In order to do that, you should prioritize hiring and training people you trust more than dictating code typed by someone else. Ultimately, you will also want to help train your own replacement to progress up.

Trust your engineers

Do not open yourself#

Because you sit atop a mountain of confidential information, you lose the ability to be fully open with your friends and coworkers, even outside of work. People look to you for confidence and leadership, so you need to be guarded about your own doubts and feelings.

Nothing is complete#

Nothing is ever complete or fully resolved, and everything is important.

Balancing middle management#

As middle management, you still have bosses. Even though while you always feel maximum responsibility for your reports’ gripes, dreams, and careers, your own impact and ability to change things are limited. This can be a difficult line to balance.

Balancing middle management

Know what you’re signing up for#

Before you decide to become a manager, read through Charity Majors’ list of 17 Reasons NOT to Be a Manager and go through Nick Caldwell’s “Voight Kampff test for engineering managers.” Know what you’re signing up for.

It’s not all bad#

It’s not all bad, or there’d be no managers. Sensible companies want to balance the risks of losing great developers with the need to grow engineering manager talent. BigCos like Facebook have the capacity to introduce temporary or “associate” EM positions where you can try it for two years (the minimum tour of duty) and move back into engineering with no consequence if you end up deciding it is not a fit.

In fact, jumping between IC and EM roles is becoming more common. Seeing things from the other side of the table for a while can make you a more effective senior IC. Christoph Nakazawa, EM of the wildly popular Jest framework and now React Native, notes:

“I’ve transitioned from IC to EM to IC to EM, and I can say that management taught me lessons on how to be a more effective engineering leader that are very hard to learn as just an IC.”

Charity Majors calls this the Engineer/Manager Pendulum:

The best individual contributors are the ones who have done time in management, and the best technical leaders in the world are often the ones who do both. Back and forth, like a pendulum.

Diversity of management advice#

There is a difference between how this game works for startups vs. BigCos. Most small companies often don’t need more than one truly senior-level engineer, and they find that they have to switch to consulting or move to a BigCo to have enough interesting projects. Conversely, at small startups, engineering managers often double as tech leads and spend significant amounts of time both coding and making technical decisions. These are completely different jobs at BigCos, and this is why you will see a wild diversity of management advice.

I cannot credibly advise you further on this track because I have not done it myself. Fortunately, many engineering leaders take writing very seriously, so you can go read their stuff.

Recommended readings

Of course, don’t spend too much time reading :) Nothing beats lived experience.

Introduction: Beyond your Coding Career

Product Management